display.framebuf is GS4_HMSB (4-bit grayscale, values 0–15), but scaled_buf is created as MONO_HLSB and the scaling writes color 1. When blitted, the ‘on’ pixels will map to value 1, which is almost black on this display (making the eye very hard to see). Consider either scaling into a GS4_HMSB buffer and using color 15 for ‘on’ pixels, or providing a palette to blit() that maps 0→0 and 1→15.

draw_eye() allocates a new scaled_bitmap bytearray and FrameBuffer on every frame. For an animation loop this creates avoidable GC pressure and can cause stutters on constrained boards. Consider pre-scaling/caching the scaled framebuffers once (e.g., at module init) and only blitting in the hot loop, or reusing a single preallocated buffer with fill(0) each frame.

The comment says the eye bitmaps are “16x16, 2 bytes per row”, which implies 32 bytes total for MONO_HLSB, but each bitmap literal below contains 33 bytes (based on the number of entries). This extra trailing byte is unused and can be confusing; consider trimming to 32 bytes or updating the dimensions/comment to match the actual data layout.

PR description/issue checklist mentions updating lib/ssd1327/README.md examples table, but this PR only adds the example file. Please add blink_animation.py to the README Examples table (or update the PR description if that task is intentionally out of scope).

This hard-codes 128 for centering. Since the display object already exposes display.width / display.height, using those would keep the example correct if the driver is instantiated with a different resolution (and avoids duplicating the docstring assumption).